home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr48 / 386p_200.zip / XVD.TXT < prev    next >
Text File  |  1995-01-11  |  14KB  |  269 lines
  1. XVD 
  2.         XGE Video Driver 
  3.         Release 0 Specification
  4.         by Lorenzo Micheletto
  5.         
  6. While devenloping XGE 2.00, one of my targets was to add more flexibility
  7. to the hardware specific subsystems.
  8. So i looked at what i was doing and where the hardware dipendence 
  9. could be bound.
  10.  
  11. Chapter I: THE XVD INTERFACE
  12.  
  13. An XVD driver as defined in release 0 of the XVD specification
  14. is a very minimalist thing, just the routines needed to check for
  15. the graphics card, set the video mode and execute paging/video-ram-allocation.
  16. Initially i planned to devenlop very complex drivers capable to "take over"
  17. lots of higher level function if needed but to do this
  18. i needed a "link while the program is running" module
  19. to "link-in" the driver code (very complex)
  20. and this "autolinker" could not restrict with safety the driver's actions
  21. (imagine a driver conceived for "cracking specific programs" or worse)
  22. so i decided to use very minimalist drivers that could be linked as they was.
  23. As a side effect of this, an XVD TYPE ZERO driver is usually less than
  24. one Kbyte long.
  25. The 386video module just checks for XVD.XVD, loads it into memory
  26. and fix-ups some offsets to complete the code/data relocation.
  27. As i said the driver has only to check for video card, set the graphics mode
  28. perform display-start, set-cpu-window and paletter read/write functions.
  29. All the other things (blitting, page update methods etc. etc.) are up to
  30. the 386video module and all the other related to graphics.
  31.    
  32. Chapter II: DRIVER SETUP  (the most critical thing)
  33.  
  34. The XVD drivers can be loaded and linked "on the run", they don't
  35. need to be distributed with your program because they can be added later
  36. to an existing game, so it is critical to use a consistent method
  37. for  NAMING and INSTALLATION of "external" drivers.
  38.  
  39. My proposal for STANDARD XVD DRIVER SETUP is the following:
  40.  
  41. A) Your SETUP PROGRAM should search ( first in the current directory
  42.    and then in the path contained into the XVD_PATH environment string)
  43.    all the *.XVD files and list them in the video card selection list
  44.    showing the descriptive strings contained into them.
  45.    (description, author/s , release date)
  46.    The setup program will COPY the selected driver to the game directory
  47.    giving to the NEW file containing the driver
  48.    the name XVD.XVD
  49.         
  50.    The setup program can be integrated into the main program
  51.    or be an external program, anyway the "game code" doesn't have to mess
  52.    with XVD_PATH or strange names, if for example it needs a 320x200 mode
  53.    it only knows it has to search into the current directory
  54.    a thing called XVD.XVD and to check if it can handle it.
  55.         
  56.    There must always be a "statically linked" driver into the game code
  57.    (i use a 320x200 generic vga driver), but if the program sees
  58.    into the current directory an external xvd driver
  59.    it must load it ( the included driver has to be used only
  60.    if there are no available drivers).
  61.         
  62. Following this method it is possible to let a game support multiple 
  63. resolutions keeping in memory only the driver in use
  64. and letting simple driver updating.
  65.  
  66. What's more you can devenlop a game including support for only
  67. the standard vga and your specific video card, other drivers will be available
  68. as public domain or included with other games.
  69.  
  70. IF YOU DEVENLOP AN XVD DRIVER, YOU SHOULD DISTRIBUITE IT AS PUBLIC DOMAIN
  71. AND WITH SOURCE INCLUDED (but you are free to ask to be payed for it).
  72. If ypu support free distribution, you will help make XVD a standard
  73. and so more games will use your graphics card to the max, and if you don't
  74. like the video driver somebody gave you,  YOU WILL BE ABLE TO CUSTOMIZE IT!!!!
  75.  
  76. You may think "Heck! I spent some time making this driver
  77. i want to be payed for this!", well, your name will be known, isn't it
  78. a good reward ? If you want money, produce a complete program with 386P+XGE
  79. and get payed for it, the program will get a wider distribution because 
  80. all the XVD drivers produced and freely distributed will let people
  81. fully exploit the graphics power of their cards and better enjoy
  82. your program.
  83. Of course, if you customize a video driver you can add your name in the
  84. credits, but you cannot delete the other names!
  85.  
  86. One of the problems with VESA games is that you have to find the driver
  87. for your card and install it properly, with XVD you just copy a file 
  88. to the game directory or let the setup program find the driver for you.
  89.  
  90. With xvd driver sources freely available, it is possible to devenlop
  91. lots of different variants for the same svga chipset getting the max
  92. from every board (i.e. some chipsets works faster if pixel transferts
  93. matches the bus size (byte,word or dword), if there is a driver
  94. for chipset xyz optimized for dword size and you want word size
  95. optimal performance, simply get the source code change some
  96. instructions and you get the max from your card).
  97.  
  98. As you can see XVD is not a super-duper-can-do-anything thing
  99. it is just a simple interface to hardware with reasonable limitations.
  100. An XVD implementation in plain vga mode 13h may look ugly, but once
  101. you get multiple display pages, XVD is really good, and if you don't like
  102. how the XGE higher level code handles the card you can rewrite it
  103. without devenlop a new driver type.
  104.  
  105. Chapter III: The driver header
  106.  
  107. ; XVD XGE Video Driver
  108. ; Header format
  109. __XVD_SIGNATURE= 0
  110.                 ; It be the four byte signature 'XVD0'
  111.                 ; XGE Video Driver TYPE ZERO, four byte file marker
  112.                 ; use it to see if the binary file is  an XVD driver
  113.                 ; now here comes the driver base relative offsets
  114.                 ; of every function supported
  115. __XVDBiosCheck=4
  116.                 ; driver-base relative pointer to  XVDBiosCheck
  117.                 ; Returns carry clear if video bios is present
  118.                 ; sets vram video pages count into driver table
  119.                 ; and available display mode mask
  120.                 ; in: edi= XVD driver table , ebp= driver base offset
  121.                 ; (the dos-extender "interface" data is located
  122.                 ;  always starting from code32 offset 0
  123.                 ;  (see head32.inc for more info)
  124. __XVDChipSetCheck=8
  125.                 ; driver-base relative pointer to XVDChipSetCheck
  126.                 ; Returns carry clear if chipset is present
  127.                 ; sets vram video pages count into driver table
  128.                 ; and availabl;e display mode mask
  129.                 ; in: edi= XVD driver table , ebp= driver base offset
  130.  
  131.                   ; currently BOTH of these must be successful
  132.                   ; to "get safe access" to the graphics extensions.
  133.                   ;
  134.                   ; If __XVDBiosCheck fails you should want the user
  135.                   ; that bios is not recognized but it is possible to
  136.                   ; test for the chipset and then try to set
  137.                   ; the video mode hoping the mode set values
  138.                   ; are not different.
  139.                   ;
  140.                   ; A future XGE release will try to use VESA functions
  141.                   ; to set the video mode if _XXVDBiosCheck fails
  142.                   ; and then if _XVDChipSetCheck is successful
  143.                   ; it will "unlock" the extensions thru direct chipset access.
  144.                   ;
  145.                   ; To use "extended" multi-page mode 13h you only have
  146.                   ; to check for the chipset (the bios entry is the same
  147.                   ; for all boards) but remember to include in the bios check
  148.                   ; the code needed to "unlock" the vga extensions.
  149.                   ;
  150.                   ; both __XVDBiosCheck and __XVDChipSetCheck
  151.                   ; must be called with:
  152.                   ; edi= XVD driver table ptr
  153.                   ; ebp= driver base address
  154.                   ; _XVDVPages,_XVDMappings,_XVDVModes and _XVDASize
  155.                   ; will be updated to what the driver supports.
  156.  
  157. __XVDMode=12
  158.                   ; driver-base relative pointer to XVDMode
  159.                   ; Set video mode
  160.                   ; eax=requested video mode
  161.                   ; edi= XVD driver table ptr
  162.                   ; ebp= driver base address
  163.                   ; returns carry clear if successful
  164.  
  165. __XVDPage=16
  166.                   ; driver-base relative pointer to XVDPage
  167.                   ; Set the current "accessible"  64k video page
  168.                   ; in: eax= video page number
  169.                   ; out: edi= LINEAR address of video page
  170.                   ;           (subtract _Code32Base to this to get
  171.                   ;            the code32 relative offset)
  172.                   ; The "accessible" video page is always 64kwide
  173.                   ; and is readable and writable.
  174.                   ; If you have a card using dual 32k cpu windows
  175.                   ; pair them into a "simulated" 64k one.
  176.                   ; If you have a card using single/dual 128k cpu windows
  177.                   ; simply "select a 64k block" into it (that's why __XVDPage
  178.                   ; returns a linear base address too)
  179.  
  180. __XVDVisible=20
  181.                   ; driver-base relative pointer to XVDVisible
  182.                   ; Set the base page of display buffer visible on screen
  183.                   ; in: eax= video page number
  184.  
  185. __XVDOpen=24
  186.                   ; driver-base relative pointer to XVDOpen
  187.                   ; Opens the "linear aperture" (maps all vram on cpu addresses)
  188.                   ; setting to the nearest aperture available on driver table
  189.                   ; (the 386video module must write on _XVDAperture
  190.                   ;  the "first" AVAILABLE PHYSICAL ADDRESS
  191.                   ;  (nor a code32 relative address neither
  192.                   ;   a "virtual memory" linear address, this functions
  193.                   ;   needs a "raw" physical address).
  194.                   ; edi=driver table, ebp=driver base address
  195.                   ; Returns CARRY CLEAR if successful
  196.                   ; And into _XVDAperture there will be the physical address
  197.                   ; the XVD driver decided to locate the linear aperture
  198.                   ; (it can be different from the initial value)
  199.                   ; then it will be up to you (using the 386power
  200.                   ; physical to code32 mapping functions) to se it up
  201.                   ; as code32 accessible memory
  202.  
  203. __XVDClose=28
  204.                   ; driver-base relative pointer to XVDCLose
  205.                   ; Closes the "linear aperture"
  206.                   ; edi=driver table  ebp=driver base offset
  207.  
  208. __XVDLineSize=32
  209.                   ; driver-base relative pointer to XVDLineSize
  210.                   ; Set scanline width
  211.                   ; in: eax= requested scanline size
  212.                   ;     edi=driver table
  213.                   ;     ebp=driver base address
  214.                   ; out: nearest scanline size set into driver table
  215.  
  216. ; RGB palette handling functions
  217. ; (identical to _Set1Pal,_Get1Pal,_Set256pal)
  218. __XVDSet1Pal=36      ; driver-base relative pointer to XVDSet1Pal
  219. __XVDGet1Pal=40      ; driver-base relative pointer to XVDGet1Pal
  220. __XVDSet256Pal=44    ; driver-base relative pointer to XVDSet256Pal
  221. __XVDCardType=48     ; driver-base relative pointer to ASCIIZ string
  222.                      ; max. 30 character long
  223.                      ; (use this in the "choose driver" list)
  224. __XVDProgrammer=52   ; driver-base relative pointer to ASCIIZ string
  225.                      ; with multiple lines of text,max. 40 char each
  226.                      ; (use the LF char (code 10h) to mark newlines)
  227.                      ; (extended info on driver)
  228. __XVDNotes=56        ; driver-base relative pointer to ASCIIZ string
  229.                      ; with multiple lines of text,max. 40 char each
  230.                      ; (use the LF char (code 10h) to mark newlines)
  231.                      ; of notes about the driver usage and supperted display
  232.                      ; cards.  (detailed info)
  233.  
  234. Appendix: Some further explanations about the XVD interface:
  235.  
  236. Into XGE you will never see XVD if you don't want to, the only thing you have
  237. to do is select the driver, the initialization code will load it
  238. and let it self-initialize, is you want to make a cool setup program
  239. you can include a "self configure" option
  240. (the setup program loads the drivers and checks for bios and chipset
  241.  using the driver detection functions), but ALWAYS include a
  242. "user driven configuration" option (some boards are hard to recognize
  243. for example my C&T 450 can pass the "bios check" for Realtek cards
  244. but it is different).
  245.  
  246.  
  247. For further info and explanations look into driver.txt, xvdriver.inc,
  248. head32.inc, 386video.txt, 386video.asm, 386video.inc, makefile
  249. and the XVD driver sources (for example chips450.asm)
  250.  
  251. If everything else fails, try to call me on the following internet addresses
  252.  knight@maya.dei.unipd.it
  253. but keep in mind that for most of 1995 i will be in the army
  254. (mandatory militar service here in Italy) so i won't access frequently 
  255. my internet account on the Engineering Department at Padova.
  256. My plain mail address is at the end of tech.txt.
  257.  
  258. Ciao,
  259.    Lorenzo Micheletto   knight@maya.dei.unipd.it
  260.                         
  261. N.B. If you want to extend the capabilities of the XVD drivers
  262.      (new functions, etc, etc) set up a portable interface
  263.      (not a thing good for your graphic card only)
  264.      and call it 'XVD1' and so on, but before doing this look into
  265.      x2ftp.oulu.fi to see if someone else did it before you, check if the
  266.      already published release is good enough, if not, publish yours
  267.      with a successive number (i.e. XVD2, XVD3, etc. etc.).
  268.  
  269.